На прошедшем анонсе новых продуктов и технологий на этот год компания VMware объявила об изменениях лицензирования, которые произойдут в продуктовой линейке VMware vSphere с 30 июня.

Давайте посмотрим, что это за изменения:

1. Снятие с производства издания vSphere Enterprise.

Да, теперь останутся только 2 издания продукта - vSphere Standard и vSphere Enterprise Plus. Позиционируется это как упрощение лицензирования. В общем-то издание Enterprise всегда было каким-то непонятным (его можно было даже назвать "Enteprise Minus", так как там просто недоставало всего пары вещей, которые были в Plus-издании). Так что этот шаг со стороны VMware хотя и запоздалый, но вполне логичный.

Помимо этого, лицензии VMware vSphere with Operations Management будут доступны только для Enterprise Plus издания. Таким образом, остаются только 3 парт-номера (SKU):

• VMware vSphere Standard
• VMware vSphere Enterprise Plus
• VMware vSphere with Operations Management Enterprise Plus

То есть, сравнительная таблица изданий VMware vSphere теперь выглядит так:

2. Бесплатные лицензии на 25 экземпляров ОС Log Insight.

Все пользователи VMware vCenter Server Standard (как существующие, так и новые) бесплатно получат лицензии на продукт vRealize Log Insight for vCenter Server на 25 экземпляров операционных систем (Operating System Instances, OSI). При этом мониторинг логов будет ограничен продуктами VMware vCenter Server, VMware vSphere и VMware vRealize Log Insight content packs.

3. Изменения цен.

Теперь VMware vSphere with Operations Management Enterprise Plus в американских цена будет стоить $4 395 за процессор хост-сервера (CPU). Ну а VMware vCenter Server Standard будет стоить $5 995 за экземпляр. В России, конечно же, все это будет стоить дороже (да-да, в долларах).

Более подробно об изменениях цен можно прочитать в следующей документе:

Компания StarWind, производитель лучшего решения Virtual SAN для создания программных отказоустойчивых хранилищ под виртуализацию, объявляет интересный конкурс. Все что вам нужно сделать, это поделиться своей историей о проекте по созданию гиперконвергентной архитектуры хранилищ (hyperconverged storage architecture), то есть архитектуры, где различные средства управления средой хранения сведены воедино в едином комплексе, а его масштабироание выполняется за счет добавления новых узлов.

Напомним, что у StarWind есть также собственное решение для создания гиперконвергентной инфраструктуры на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager. Поставляется оно в виде готового программно-аппаратного комплекса.

Итак, участвуйте в конкурсе StarWind и выиграйте 500 баксов:

Ваши истории появятся в блоге StarWind, а вы и ваши друзья и коллеги смогут проголосовать за них. Сами истории принимаются до 15 апреля, а уже 18 апреля будет объявлен победитель, который и получит 500 долларов. Те, кто займет второе и третье места, получат призы $300 и $150 соответственно.

В преддверии глобального анонса продуктов и технологий на 2016 год, компания VMware опубликовала несколько новостей о новых продуктах, в частности о решении для виртуализации пользовательских окружений VMware Horizon 7.

Давайте детально посмотрим на новые возможности, которые нам обещают в Horizon 7 в рамках анонса:

1. Полноценное использование технологии Instant Clone Technology.

Мы уже писали об этой технологии, которая позволяет "на лету" создать клон виртуальной машины, а следовательно практически мгновенно развернуть новый виртуальный ПК, каждый из которых будет использовать данные базовой машины (общая память на чтение). В сочетании с технологией доставки приложений через подключаемые виртуальные диски VMware App Volumes 3.0 и средством управления окружениями User Environment Manager, эти возможности позволят пользователям мгновенный доступ к своим данным, при этом рабочая машина пользователя не будет "загрязняться" ненужными устанавливаемыми программами и ключами реестра.

Приложения уже будут поступать в машину виртуализованными, упакованными и готовыми к использованию, а пользователь всегда может отключить их или подключить новые сервисы. И все это будет работать быстро, так как в силу технологии App Volumes винда не будет стареть и тормозить, а сами десктопы будут доступны к использованию мгновенно. Достигаться это будет посредством того, что при отключении пользователя его десктоп будет уничтожаться, а при подключении - на лету собираться средствами Instant Clone и App Volumes.

Десктоп пользователя = (мгновенный клон родительской ВМ) + (корпоративные приложения на дисках App Volumes) + (данные пользователя) + (установленные пользователем приложения)

Патчинг приложений теперь выглядит совершенно по-иному - теперь можно обновлять их в рамках App Volumes, а пользователь получает обновленное приложение уже при следующем логине. Ну и теперь никаких Boot Storms при одновременном логине пользователей - ведь десктопы всегда включены.

Все это будет возможно на Virtual Hardware версии 11. Пока будут поддерживаться только плавающие (floating) пулы виртуальных ПК, но в следующей версии будут поддерживаться и dedicated-десктопы. Ну и NVIDIA GRID пока для таких десктопов поддерживаться не будет.

2. Умные политики для устройств пользователей в зависимости от условий логина.

В инфраструктуре виртуальных ПК администраторы и менеджеры информационной безопасности больше всего волнуются о соблюдении требований, касающихся защиты конечных устройств (см. нашу статью о том, как украсть виртуальную машину).

Теперь в VMware Horizon View 7 появляются "умные политики" (Smart Policies), которые позволяют в зависимости от способа логина пользователя применять те или иные правила. Например, пользователю, который логинится через сеть разумно отключить копирование на USB-устройство, перенаправление клавиатуры и возможность печати. Также можно, например, кастомизировать полосу пропускания по протоколу PCoIP, в зависимости от типа логина пользователя.

Обзор функции Smart Policies:

Также Identity manager обеспечивает простоту логина уже аутентифицированного пользователя к любым выбранным объектам своего окружения посредством генерации временных сертификатов при запросе объектов пользователем.

3. Улучшения доступа к консоли машины для мобильных устройств и протокол Blast Extreme.

Теперь технология веб-доступа к консоли виртуальной машины Blast Extreme полноценно включена в стек протоколов доступа вместе с PCoIP и RDP. С помощью этой технологии можно иметь быстро работающее устройство с консолью виртуального ПК на разрешении до 4К. Blast Extreme заточена под мобильные устройства, что выражается в том, например, что сам протокол заботится об уменьшении нагрузки на CPU и более долгой жизни батареи.

Также Blast Extreme теперь оптимизирован для нагрузок в виртуальных ПК, которые используют технологию NVIDIA GRID (поддерживаются карточки K1, K2, M6 и M60). Поскольку в среде NVIDIA GRID большая часть нагрузки CPU ложится на плечи vGPU, то это позволяет достичь синергичного эффекта для технологии Blast Extreme. Все это вместе дает до 18% больше пользователей на сервере, увеличение на 6-13% фреймрейта, уменьшение latency на величину до 51 мс, а также снижение требований к пропускной способности канала на 48-89%. Если это все так, то это супер-круто. О подробностях можно прочитать в блоге NVIDIA.

4. Возможности Horizon Access Point.

Это альтернатива Security Server в VMware View, которая позволяет защитить инфраструктуру VMware Horizon View при доступе извне. Может быть настроен для протоколов RADIUS или RSA SecurID:

5. Поддержка режима vSGA для адаптеров AMD.

Вслед за поддержкой технологий NVIDIA, компания VMware постепенно наращивает поддержку адаптеров AMD. Сейчас для них будет поддерживаться режим vSGA:

Будет обеспечена поддержка технологии AMD SR-IOV (single root I/O virtualization), нативных драйверов AMD для аппаратного ускорения OpenGL, DirectX и OpenCL. Кроме того, обещают сертификацию для приложений Solidworks, PTC и Siemens.

6. Превью технологии Flash Redirection.

Эта технология позволяет перенаправить flash-контент на конечное устройство пользователя и там уже рендерить его. Пока данная технология доступна в статусе Tech Preview.

7. Поддержка Intel vDGA Graphics с последними процессорами Intel Xeon E3.

Теперь для режима прямого проброса vDGA поддерживаются интегрированные модули Iris Pro GPU совместно с технологией Intel Graphics Virtualization Technology (Intel GVT-d).

8. Улучшения печати и Windows 10.

Теперь печать из виртуального ПК работает до 4 раз быстрее, а для Windows 10 улучшена поддержка сканеров и проброса последовательных портов.

9. Функции URL Redirection.

Мы уже писали о Flash URL Redirection, здесь механизм работы такой же. Администратор может задать какие адреса можно открывать локально, внутри виртуального ПК (безопасно), а для каких потребуется запускать браузер на хостовой машине (все остальное).

10. Обновленные клиенты VMware Horizon Client 4.0.

Horizon Client 4.0 Windows:

• Полная поддержка Blast Extreme и аппаратного ускорения.
• Предоставляет масштабируемое разрешение для лучшей читабельности.
• Автошаринг USB-устройств для Client Drive Redirection (улучшено).
• Быстрее работает печать.
• Быстрее работает по сети WAN через Security Server.
• Обновленные OpenSSL и TLS.
• Поддержка работы на Windows Server 2012.

VMware Horizon Client 4.0 Mac:

• Полная поддержка Blast Extreme.
• Работает со сплит-вью в OS X El Capitan.
• Улучшения полноэкранного режима и при работе с несколькими мониторами.
• Открытие локальных файлов через Horizon hosted apps.
• Быстрее работает печать.
• Быстрее работает по сети WAN через Security Server.
• 64-битная версия клиента.
• Запоминание username/domain при логине.
• Обновленные OpenSSL и TLS.

VMware Horizon Linux Client 4.0:

• Поддержка RHEL 7.2 x64 и Ubuntu 14.04 x64.
• Полная поддержка Blast Extreme.
• Быстрее работает печать.
• Быстрее работает по сети WAN через Security Server.
• Режим FIPS для Blast Extreme, PCoIP и USB.

VMware Horizon iOS Client 4.0:

• Split view для iPad Air 2 и iPad Pro.
• Полная поддержка Blast Extreme и аппаратного ускорения.
• Использование Apple Pencil как мышки.
• Real-time Audio при использовании микрофона.
• Улучшенные настройки (доступны в самом клиенте).
• Обновленные OpenSSL и TLS.

VMware Horizon Android Client 4.0:

• Поддержка доступа через Android Fingerprint
• Полная поддержка Blast Extreme и аппаратного ускорения.
• Real-time Audio при использовании микрофона.
• Возможность использования внутреннего хранилища для приложений в виртуальном ПК.
• Обновленные OpenSSL и TLS.

VMware Horizon Chrome OS Client 4.0:

• Полная поддержка Blast Extreme.
• Возможность использования хранилища Google Drive и USB-хранилища для приложений в виртуальном ПК.

HTML Access 4.0:

• Поддержка Linux-десктопов работает на мобильном Safari в iOS.
• Поддержка F5 APM (Access Policy Manager).

11. Улучшения VMware Horizon for Linux.

Тут можно отметить следующие вещи:

• Поддержка SLED 11 SP3.
• Операции copy/paste между Linux-ПК и клиентской ОС.
• Поддержка vGPU для RHEL 7.x (6.2.1).
• Работа SSO для RHEL 6.6 и CentOS 6.6 без смарт-карт (6.2.1).

12. Режим Horizon Air Hybrid mode.

Этот режим предоставляет возможности для построения следующей архитектуры:

• Десктопы и приложения располагаются локально (on-premise).
• Панель управления облачной инфраструктурой доступна как SaaS.

13. Улучшения масштабируемости и гибкости.

Здесь 3 основных моменты:

• Теперь в архитектуре Cloud pod может быть до 10 POD'ов на 4 площадках с числом десктопов до 50 000.
• Cloud pod architecture (CPA) позволяет назначение прав на сайт для вложенных AD security groups.
• Улучшенная поддержка отказоустойчивости - если ресурсы сайта недоступны, пользователь автоматически перенаправляется до другой сайт, где его ждет резервный десктоп.

Как всегда, VMware сделала очень большой шаг вперед в плане инфраструктуры виртуальных ПК, и, как мне кажется, VMware Horizon 7 будет реальным убийцей продукции Citrix. Если даже и не в технологическом плане, то уж в пиар-плане так точно. Ждем доступности продукта в этом году!

Мы часто пишем о веб-консоли для управления отдельными хост-серверами VMware ESXi Embedded Host Client, которая для многих администраторов уже стала инструментом, используемым каждый день. На днях компания VMware выпустила обновленную версию ESXi Embedded Host Client v5, которая доступна для загрузки на сайте проекта VMware Labs.

На самом деле, нового в VMware ESXi Embedded Host Client 5 не так много, но говорят, что было исправлено очень много багов:

Хост-серверы

• Улучшения в разделе мониторинга производительности (ресайз и поведение тултипов).

Виртуальные машины

• Возможность простого экспорта виртуальной машины (базовые функции).
• Поддержка клавиатур IT/ES в браузерной консоли.
• Исправлены серьезные ошибки при операциях с дисковым контроллером (добавление/удаление, назначение дисков и т.п.).

Хранилища

• Исправлена сортировка в datastore browser.

Общие улучшения

• Улучшенное поведение таблиц (включая возможности выбора объектов, колонок и фильтрации).
• Более производительная панель Recent Tasks.
• Улучшенная производительность таблицы виртуальных машин.
• Улучшенное поведение контекстных меню на iPad.
• Возможность перетаскивать и ресайзить окна и диалоги на iPad.
• Множество исправлений ошибок.

Скачать VMware ESXi Embedded Host Client 5 можно по этой ссылке. Кстати, таблица совместимых браузеров:

Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.

Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.

В этом случае Site Locality лучше отключить и не прогревать кэш каждый раз при миграциях в рамкха растянутого кластера с высокой пропускной способностью сети. Сначала запросим значение Site Locality:

[root@esxi-01:~] esxcfg-advcfg -g /VSAN/DOMOwnerForceWarmCache


Value of DOMOwnerForceWarmCache is 0

Устанавливаем значение в 1, если хотим отключить принудительный прогрев кэша при смене площадки размещения машины:

[root@esxi-01:~] esxcfg-advcfg -s 1 /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 1

Весьма интересный вебинар скоро проведет компания StarWind, выпускающая лучший на рынке продукт Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V. На бесплатном онлайн-мероприятии "How to Get All-Flash Performance with Intel SSD and StarWind HyperConverged Appliance" сотрудники StarWind расскажут о том, как с помощью программно-аппаратного модуля StarWind HyperConverged Appliance построить надежную архитектуру хранения небольшого предприятия или филиала с наибольшей производительностью и максимальным уровнем отказоустойчивости.

Вебинар пройдет 10 февраля в 22-00 по московскому времени. Макс Коломейцев ответит на все ваши вопросы на русском языке. Регистрируйтесь!

С удовольствием представляем вам очередного спонсора VM Guru - компанию AFI Distribution, осуществляющую поставку замечательного продукта для резервного копирования виртуальных машин - Altaro VM Backup.

Altaro VM Backup — простое в использовании решение для резервного копирования, надежного хранения и восстановления виртуальных машин на базе Hyper-V и VMware. Программа имеет легкий и понятный интерфейс, интуитивную настройку, а самое главное - безотказно работает.

15 минут на установку и создание первых копий машин – никаких сложных настроек и установки вспомогательного ПО не требуется. Стоимость не зависит от количества ядер и виртуальных машин: лицензируются только хосты, с которых будет идти резервное копирование машин.

Резервное копирование без остановки виртуальной машины

Копирование «на лету» для виртуальных машин под управлением ОС Windows и Linux, включая машины с MS Exchange и MS SQL на борту.

Создание копий сразу в несколько хранилищ

Altaro VMBackup создаст для вас несколько копий виртуальных машин для надежности, при этом поддерживаются следующие хранилища:

• Носители, подключаемые по USB
• Внешние диски eSATA
• Сетевые папки, доступные по UNC
• NAS-устройства, доступные по UNC
• Локальные жесткие диски (рекомендуется использовать только для тестирования продукта)
• Картриджи RDX
• Внешние сервера, доступные через Интернет/WAN

Автоматическая чистка

Старые копии могут быть автоматически удалены по расписанию, а также после того, как новые копии будут проверены на работоспособность. Время хранения копий на различных хранилищах можно настраивать отдельно.

Шифрование копий на внешних серверах

Вы ведь не хотите, чтобы копию виртуальной машины кто-нибудь утащил с внешнего сервера? Мы позаботились об этом – каждая копия зашифрована надежным алгоритмом AES!

Восстановление машины или ее клона на тот же или любой другой хост

Вы можете восстанавливать копии машин куда угодно – лицензия не требуется! На тот же хост, заменив работающую (утерянную) машину, в виде клона машины, а также на любой другой хост.

Вся ваша сеть видна из единой консоли управления, чтобы вы не тратили в самый ответственный момент ни минуты лишнего времени на выбор хоста для восстановления резервных копий.

Восстановление отдельных файлов и писем из резервной копии

В панель управления встроен проводник по файлам и письмам резервных копий – вы можете восстановить любой элемент всего в пару кликов, моментально!

Периодическая проверка работоспособности копии

Хорошая резервная копия – та, что может быть восстановлена в случае аварии, не так ли? Altaro VMBackup ответственно проверит каждую сделанную копию прежде, чем вам понадобится ею воспользоваться. И когда мы говорим о проверке копии, мы имеет в виду не просто проверку на читаемость и целостность, а самую настоящую проверку на работоспособность в специальном тестовом окружении.

Поддержка на русском языке!

Наши специалисты не только поддержат вас в любых вопросах по телефону и электронной почте, но и с радостью покажут работу продукта «живьем» на наших серверах, а также установят и настроят решение в вашей сети «под ключ» совершенно бесплатно!

Для англоговорящих клиентов доступны чат со специалистом и автоматические рекомендации по устранению проблем прямо из интерфейса Altaro VMBackup.

Скачать решение Altaro VMBackup можно бесплатно по этой ссылке (там же есть и онлайн-демо продукта, попробуйте).

Некоторое время назад мы писали о документе VMware Lifecycle Product Matrix, описывающем жизненный цикл продуктов VMware. В январе 2016 года вышла обновленная версия этого документа:

Напомним основные стадии жизненного цикла продуктов VMware:

• Genetral Availability - официальная доступность продукта для загрузки, с даты которой начинается General Support Phase.
• General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится определенное время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя) получают апдейты и апгрейды, багофиксы и фиксы безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.
• Technical Guidance Phase - эта фаза (если она доступна) начинается с момента окончания предыдущей фазы и длится заданное время. Здесь уже предоставляются инструкции через портал самообслуживания, а по телефону звонки не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.
• End of Support Life (EOSL) - в этой фазе продукт уже не поддерживается VMware. Это означает окончание первых двух фаз. Кроме этого, здесь происходит прекращение продаж продукта.
• End of Availability (EOA) / End Of Distribution (EOD) - в этом режиме продукт уже не поддерживается, и он недоступен на сайте VMware, то есть его, попросту говоря, нельзя скачать.

Более подробно обо всем этом - в документе.

Компания VMware в своем блоге, посвященном продуктам линейки VMware vSphere, представила интереснейшее доказательство, что кластер VMware Virtual SAN дает надежность "шесть девяток", то есть доступность данных 99,9999% времени в году. А это меньше, чем 32 секунды простоя в год.

Бесспорно, приведенное ниже "доказательство" основано на множестве допущений, поэтому заявление о шести девятках является несколько популистским. С моей точки зрения, гораздо более вероятно, что админ с бодуна не туда нажмет, или, например, в команде vmkfstools укажет не тот LUN и снесет все виртуальные машины на томе VMFS (привет, Антон!), чем откажет оборудование с дублированием компонентов. Но все же, рассмотрим это доказательство ниже.

Прежде всего, введем 2 понятия:

• AFR – Annualized Failure Rate, то есть вероятность отказа в год (носителя данных или другого компонента), выраженная в процентах.
• MTBF – Mean Time Between Failures (среднее время между отказами). Это время в часах.

Эти 2 величины взаимосвязаны и выражаются одна через другую в соответствии с формулой:

AFR = 1/(MTBF/8760) * 100%

Обычно, как HDD, так и SSD накопители, имеют AFR от 0.87% до 0.44%, что дает от 1 000 000 до 2 000 000 часов MTBF. Далее для примера берут диск 10K HDD от Seagate (популярная модель ST1200MM0088), для которой AFR равен 0.44% (см. вторую страницу даташита) или 2 миллиона часов в понятии MTBF. Ну и взяли популярный SSD Intel 3710 для целей кэширования, который также имеет MTBF на 2 миллиона часов.

Для того, чтобы вычислить время доступности данных на таких накопителях, нужно понимать время, которое необходимо для восстановления бэкапа на новый накопитель в случае сбоя. По консервативным оценкам - это 24 часа. Таким образом, доступность данных будет равна:

2 000 000/ (2 000 000 + 24) = 0,99998

То есть, 4 девятки. Но диск - это еще не весь сервис. Есть еще надежность дискового контроллера, самого хост-сервера и стойки в целом (по питанию). VMware запросила данные у производителей и получила следующие параметры доступности:

• Rack: 0,99998
• Host: 0,9998
• Controller: 0,9996

Итого, мы имеем доступность:

0,99998 (Rack) * 0,9998 (Host) * 0,9996 (Controller) * 0,99998 (SSD Cache) * 0,99998 (SSD/HDD Capacity) = 0,9993

Вот, доступность уже 3 девятки, что эквивалентно 8,76 часов простоя в год. Не так плохо, но это слишком оптимистичные значения - на деле есть прочие факторы, влияющие на доступность, поэтому уберем последнюю цифру из долей для доступности каждого из компонентов:

0,9999 (Rack) * 0,999 (Host) * 0,999 (Controller) * 0,9999 (SSD Cache) * 0,9999 (SSD/HDD Capacity) = 0,997

Получается 2 девятки, а это 3,65 дня простоя в год, что уже довольно критично для многих бизнесов.

Ну а теперь применим технологию VMware Virtual SAN, которая дублирует данные на уровне виртуальных машин и отдельных виртуальных дисков. Если мы используем параметр FTT (Numbers of failures to tolerate) равный 1, что подразумевает хранение одной реплики данных, то вероятность недоступности хранилища Virtual SAN данных будет равна вероятности отказа 2-х хранилищ одновременно, то есть:

(1-0.997)^2 = 0.00000528

Ну а доступность в данном случае равна:

1-0.00000528 = 0.999994

То есть, уже 5 девяток. Но это доступность для одного объекта VSAN, а отдельная виртуальная машина обычно имеет несколько объектов, допустим, 10. Тогда ее доступность будет равна:

0.999994^10 = 0.99994

В итоге, 4 девятки. Это 52,56 минуты простоя в год. В зависимости от того, сколько объектов у вас будет на одну ВМ, вы будете иметь доступность от 4 до 5 девяток.

А теперь возьмем FTT=2, то есть конфигурацию, когда имеется 2 дополнительных копии данных для каждого объекта в кластере Virtual SAN. В этом случае вероятность полного отказа всех трех копий данных:

(1-0.997)^3 = 0.00000001214

А доступность для ВМ с десятью объектами:

0.999999988^10 = 0.999999879

То есть, те самые 6 девяток, о которых говорится на слайде. Конечно, все это допущения, фантазии и игра с вероятностями, но читать это все равно интересно. Еще более интересно то, что оригинал этой статьи написала женщина)

Мы уже не раз касались решения VMware App Volumes (ранее это был продукт Cloud Volumes), предназначенного для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Буквально вчера компания VMware анонсировала обновленную версию App Volumes 3.0, где появилось несколько существенных нововведений.

Итак, что именно появилось нового в App Volumes 3.0:

• AppToggle – это технология, предоставляющая возможности установки приложений и безопасного назначения прав (до этого приложения просто прятались) пользователям в рамках одного тома AppStack. Это снижает число необходимых томов для обслуживания, упрощает управление ими и увеличивают производительность. Этот архитектурный подход позволяет приложениям внутри одного AppStack иметь взаимозависимости и расшаривать их между другими приложениями, что дает высокую степень гибкости развертывания инфраструктуры App Volumes.
• AppCapture with AppIsolation – теперь технология AppCapture имеет интерфейс CLI, а также интегрирована с продуктом VMware ThinApp, что позволяет в рамках одного AppStack собирать физически устанавливаемые и виртуализованные приложения для доставки их отдельным пользователям и рабочим группам. Теперь процесс доставки приложений, их обновления и контроля изоляции друг от друга становится весьма простым (например, раньше нужно было запускать ThinApp, а потом отдельно средства AppCapture).
• AppScaling with Multizones – теперь если у вас несколько датацентров, то App Volumes предоставляет средства для развертывания одних и тех же AppStacks на нескольких площадках. Если раньше нужно было вручную заботиться о репликации хранилищ приложений, то теперь App Volumes можно интегрировать с экземплярами vCenter на каждой из площадок и выбрать, куда задеплоить (отреплицировать) нужные AppStacks с приложениями пользователей. Сканирование датасторов в датацентрах на предмет синхронизации AppStacks будет проходить с заданным интервалом времени.
• Integrated Application, User Management and Monitoring Architecture – новая архитектура App Volumes собирает в одном месте функции управления приложениями и их жизненным циклом, окружениями и правами пользователей, а также средства мониторинга инфраструктуры App Volumes. Решение интегрировано с унифицированным средством мониторинга виртуальной инфраструктуры vRealize Operations Manager.
• Unified Administration Console ­– исходня из прошлого пункта, теперь все функции решения собраны в одной консоли администратора (Astro console). Этот администратор настраивает инфраструктуру физических и виртуальных приложений, которая масштабируется на один или несколько датацентров на виртуальных ПК пользователей.

Решение VMware App Volumes 3.0 будет поставляться в трех изданиях:

О доступности VMware App Volumes 3.0 будет объявлено дополнительно.

Компания Microsoft на днях выпустила технологическое превью пакета Microsoft Azure Stack TP1, который представляет собой набор средств для создания гибридной инфраструктуры Azure в вашем датацентре. Это что-то вроде Azure Pack по форме, но по смыслу совершенно иное. Многие компании не могут полностью переехать в публичное облако, хотя и довольно широко используют возможности Azure, завязывая многие административные процедуры и интерфейсы именно на облачную инфраструктуру. При этом оставшиеся в датацентры сервисы приходится "прилаживать" к инфраструктуре Azure, что рождает сложности в администрировании.

Поэтому и вышел Microsoft Azure Stack - он позволяет получить свой собственный Azure в своем ЦОД и управлять гибридной инфраструктурой как единым целым:

То есть, в данном случае, Microsoft вводит собственное понятие облака - это не место, где располагаются данные или сервисы, а совокупность методов управления виртуальными ресурсами на базе различных интерфейсов.

Технологически, Azure Stack - это набор виртуальных машин, каждая из которых реализует набор сервисов, к которым администраторы привыкли в облаке Azure:

Все это позволяет использовать такие общие средства, как, например, Azure Portal в онпремизной инфраструктуре:

С помощью Azure Resource Manager можно верхнеуровнево управлять своей облачной инфраструктурой, не погружаясь в детали, собственные ли это ресурсы или облачные. Все так же устроено по принципу виртуальных клиентов датацентра (тенантов), которые запрашивают ресурсы датацентра или облака (подход к этому унифицированный).

Эти тенанты имеют подписки (subscription), в рамках которых есть оффер с набором планов (групп сервисов):

Собственно, на базе подписок и формируется стоимость потребляемых тенантом ресурсов облака (например, отделом бухгалтерии).

Чем это все полезно на практике? Ну, например, в облаке Azure вы развертывали новые сервисы на базе шаблонов Azure Resource Manager Templates в формате JSON. Теперь вы сможете продолжить это делать, но уже и у себя, в собственной инфраструктуре. Ну и, в целом, теперь административные операции с сервисами придут к одному образу действий администраторов.

Более подробно об Azure Stack можно прочитать в документации или на специальной странице Azure Stack. Скачать решение (сейчас оно пока не предназначено для производственного использования, а рекомендуется только для тестов) можно по этой ссылке.

Компания VMware выпустила очень интересный документ "VMware vSphere 6 Fault Tolerance Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.

Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.

1. Процедура компиляции ядра в гостевой ОС.

Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:

2. Сетевая активность.

Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:

Кстати, очевидно, что сетевой трафик именно самой сети FT максимальный, когда машина принимает много данных (их нужно синхронизировать на второй узел), когда же данные передаются там трафик намного меньше (машина их просто отдает, а синхронизировать нужно только сам процесс передачи и параметры канала).

Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:

Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:

3. Тестирование подсистемы ввода-вывода.

Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:

4. Тест Swingbench для Oracle 11g.

Для теста была взята OLTP-нагрузка на базу данных. По числу транзакций в секунду потери небольшие, но задержка по времени ответа возникает значительная:

5. Тест DVD Store на Microsoft SQL Server 2012.

Здесь была запущена симуляция 64 пользовательских сессий. По-сути, этот тест очень похож на методику для Oracle, ну и результаты здесь также соответствующие (но по времени отклика как-то все очень печально):

6. Бенчмарк на базе TPC-E.

Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:

7. Операции VMware vCenter Server.

Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:

vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:

Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.

Тем из вас, кто администрирует инфраструктуру Microsoft, может оказаться интересным технологический блог компании StarWind Software, которая производит лучшее средство для создания отказоустойчивых хранилищ для инфраструктуры Hyper-V - Virtual SAN.

В своем блоге сотрудники компании рассказывают об интересных фишках, например, есть посты от основателя и CTO компании Антона Коломейцева о том, как сделать бесплатный SMB 3.0 сервер на бесплатном Hyper-V Server, да еще и в кластерной конфигурации:

Или вот настройка Storage Spaces Direct в 4-узловой конфигурации. Подписывайтесь, в общем - там есть форма для ввода почты.

По завершении 2015 года группа компаний "ИТ-ГРАД" успешно прошла аудит на соответствие требованиям стандарта PCI DSS, сертифицировав не только физическое размещение, как это делает сегодня большинство поставщиков услуг, но и виртуальную инфраструктуру, а также процессы администрирования. "ИТ-ГРАД" стал одним из первых в России поставщиком услуг с управляемыми сервисами PCI DSS, или MSP-провайдером (PCI DSS Managed Service Provider). Такая сертификация позволяет предоставлять в соответствии с требованиями стандарта услуги не только по физическому размещению и аренде оборудования, но и по аренде виртуальной инфраструктуры в модели IaaS, а также администрированию и управлению этой инфраструктурой.

В рамках полученного MSP-статуса "ИТ-ГРАД" представляет сертифицированное по PCI DSS облако в модели IaaS, гарантируя безопасное обращение платежных карт для организаций, разместивших свою инфраструктуру на стороне облачного поставщика, где хранятся, обрабатываются или передаются данные платежных карт. "ИТ-ГРАД" берет на себя ответственность по выполнению обязательных требований стандарта, начиная от физической защиты размещаемых серверов до администрирования операционных систем, а также обеспечивает соблюдение требований безопасности, гарантируя защиту облачной инфраструктуры и постоянный контроль за ее безопасностью.

"Миграция критически важных систем за пределы внутренней инфраструктуры компании связана с высоким уровнем доверия. В такой ситуации клиент должен быть уверен в надежности выбранного поставщика и в том, что обработка конфиденциальной информации происходит защищенным образом, а угрозы нарушения безопасности сведены к минимуму. В "ИТ-ГРАД" мы внедрили полный набор механизмов обеспечения безопасности, чтобы надежно контролировать и защищать клиентские системы. Мы следуем и соответствуем требованиям федерального законодательства в области информационной безопасности, обязательным индустриальным нормам и практикам проведения регулярных независимых аудитов. Благодаря внутренним регламентам и практикам компании "ИТ-ГРАД" сосредоточен на защите данных своих клиентов. Чтобы заработать доверие и обеспечить защиту систем и данных держателей платежных карт, мы прошли сертификацию на соответствие требованиям стандарта PCI DSS v.3.1", — комментирует Дмитрий Третьяков, менеджер по информационной безопасности "ИТ-ГРАД".

"Услуги по предоставлению управляемых сервисов в контексте сертифицированного по PCI DSS облака в модели IaaS являются весьма актуальными для российского рынка. Особенность таких услуг заключается не только в предоставлении поставщиком оборудования в аренду, но и аренды виртуальной инфраструктуры, а также возможности ее администрирования в соответствии с требованиями стандарта PCI DSS. Такая услуга особенно полезна для небольших торгово-сервисных предприятий и поставщиков услуг, не имеющих собственных ИТ- и ИБ-подразделений. Обращение к сертифицированному поставщику, такому как "ИТ-ГРАД", поможет предприятиям существенно упростить процесс сертификации по стандарту PCI DSS и обеспечить защиту данных держателей платежных карт на высоком уровне", — отмечает Петр Шаповалов, инженер по защите информации ООО "Дейтерий", PCI QSA.

Используя сертифицированное по стандарту PCI DSS облако в модели IaaS, организации смогут значительно повысить уровень защищенности среды обработки карточных данных, снизив риски финансовых потерь от всевозможных инцидентов в сфере информационной безопасности. В рамках пройденного "ИТ-ГРАД" аудита на соответствие требованиям стандарта PCI DSS услуга по использованию сертифицированного облака в модели IaaS поможет компаниям наиболее полно воспользоваться преимуществами аутсорсинга в области выполнения требований стандарта, сосредоточив усилия на развитии своего бизнеса.

Вслед за финансовыми итогами компании VMware, которые мы рассматривали вчера, компания Citrix также выпустила годовой отчет за 2015-й фискальный год. Он доступен по этой ссылке. Напомним, что в прошедшем году Citrix должна была сократить 900 сотрудников (700 работающих на фултайм и 200 контрактных работников). О прошлом годовом отчете Citrix мы писали вот тут.

И это сработало! Результаты Citrix, по сравнению с прошлым годом, очень даже неплохи:

Компания уволила разгильдяев и бездельников, и показатели вышли в плюс! В следующем году Citrix планирует выручку на уровне 3,31-3,32 миллиарда долларов. Более детальная информация по показателям:

Также напомним тут о нашей статье про идущий ко дну Citrix вот тут, но может все не так уж и плохо. Сейчас компания уволит еще больше оптимизирует структуру и может что-то технологически новое придумает. Кстати, совсем недавно CEO компании Citrix стал наш с вами соотечественник Кирилл Татаринов.

Представляем вам очередной гостевой пост компании 1cloud - облачного провайдера, предоставляющего услуги виртуальной инфраструктуры в аренду. Как обычно, 1cloud рассказывает об интересных технологиях и подходах к организации ИТ-инфраструктуры предприятия.

В ходе состоявшейся в 2013 году конференции Google Tech Talks глава подразделения по обеспечению надежной работы Google Раймонд Блум рассказал о том, как в компании устроен процесс резервного копирования данных. Как пишет издание High Scalability, Google не раскрывает точный объём данных, хранящихся в дата-центрах компании, однако по косвенным признакам на момент выступления Блума можно было судить, если не о йоттабайтах, то о многих экзабайтах данных. Один только Gmail содержит экзабайты информации.

По словам Раймонда Блума, привычные техники бэкапа не подходят для Google, поскольку при их использовании с увеличением емкости инфраструктуры растет и количество усилий на ее поддержку. В масштабах Google подход при котором увеличение хранимых объёмов данных в два раза требует в два раза больше усилий по их сохранению просто не будет работать. Необходимо иметь возможность масштабировать инфраструктурные мощности быстрее, чем будет расти потребность в них. Бэкап одного экзабайта данных и бэкап двух экзабайтов — это «две большие разницы». Блум рассказал о том, как компания с этим справляется, а мы представляем вашему вниманию главные тезисы этого выступления.

Вот видео выступления инженера Google:

 

А ниже представлена расшифровка основных озвученных подходов к хранению данных и тезисов его рассказа:

• Никаких потерь данных, никогда. Даже во время масштабного сбоя Gmail в 2011 году, в конечном счете никаких потерь данных не произошло. Такого результата удалось достигнуть не только благодаря использования технологий копирования на магнитную ленту. Данные были собраны со всех уровней стека технологий Google, что потребовало серьезных инженерных усилий.
• Бэкапы бесполезны. Главная задача – восстановить данные. Бэкап – это своего рода налог, который вы платите за роскошь все восстановить в лучшем виде. Поэтому-то и нужно делать резервное копирование настолько изощренными, чтобы сам процесс восстановления был прост и понятен даже младенцу.
• Система не масштабируется линейно. Грубо говоря, если количество информации выросло в сотню раз, это не значит, что вам достаточно в 100 раз увеличить количество человеческих ресурсов и машин. Здесь действуют увеличивающие коэффициенты. Только автоматизация процессов позволит нарастить эффективность и возможности системы.
• Чрезмерность во всем. Сбои софта и железа случают регулярно. Так умирают клетки в нашем организме. Google не питает иллюзий, что все будет жить вечно, компания должна быть готова к тому моменту, когда очередной компонент системы откажет.
• Диверсификация процессов. Если важна доступность, то данные лучше хранить не в одном месте. Если необходимо учитывать возможные ошибки пользователей, следует создавать уровни доступа. Чтобы не зависеть целиком от одной системы в случае ее сбоя, следует использовать разные варианты софта.
• Снимите с людей петлю. Пользователей не волнует, сколько резервных копий их писем хранит Gmail. В системе есть стандартные установки, которые должны работать всегда. Есть некий уровень сервиса, и не надо тревожить пользователя, пока не случится действительно нечто из ряда вон.
• Нужны доказательства. Если не пробовать, ничего не будет работать. Бэкапы и восстановления постоянно тестируют, чтобы удостовериться в их возможностях.

Далее идут заметки автора материала на сайте High Scalability, который выписал главные мысли Блума...нажмите, чтобы читать дальше

Компания VMware на днях опубликовала пресс-релиз с квартальным и годовым отчетом за 4-й квартал 2015 года и весь 2015 год, соответственно. Напомним, что о прошлом отчете мы писали вот тут, а финансовые отчеты за все прошлые года доступны тут.

Давайте посмотрим на результаты 2015 года в сравнении с результатами 2014:

Интересны также 3 вывода из пресс-релиза:

• Решения VMware в области End-User Computing растут на 30% в год, и сейчас сумма заказов за год составляет 1,2 миллиарда долларов.
• В 2015 году бизнес по продаже решения для виртуализации сети датацентра VMware NSX вырос в 2 раза и составляет $600 миллионов.
• Если брать в расчет 4-й квартал 2015 года, то бизнес по продаже решения VMware Virtual SAN вырос в 3 раза, а сумма заказов достигла 100 миллионов долларов.

Пока компания продолжает расти и наращивать активы, вроде бы все хорошо. Но. В целях повышения операционной эффективности компания VMware планирует уволить 800 человек (в отчете это скрывается за мягким выражением "restructuring and realignment"), а это уже первая ласточка насытившегося рынка.

Также вот тут пишут, что команды VMware Workstation и VMware Fusion полностью уволены. Это подтверждается вот этим постом теперь уже бывшего сотрудника VMware. На данный момент не очень понятно, что будет с самими продуктами. Хотя, как они могут продолжить жить без команд их разрабатывающих?

Всем интересующимся технологиями виртуализации интересно, что же нового готовит компания VMware в своей продуктовой линейке в 2016 году. Специально для вас компания VMware проводит серию онлайн-мероприятий под названием "Enabling the Digital Enterprise", где будут озвучены основные технологические направления виртуализационного гиганта.

Программа мероприятия разбита на треки, посвященные основным направлениям деятельности компании:

Track 1 – Deliver and Secure Your Digital Workspace

Здесь, очевидно, речь пойдет о доставке пользовательских окружений и защите решений в сфере виртуализации приложений и настольных ПК. Попросту говоря, будет рассказано о том, что нового появится в линейке VMware Horizon. Мероприятие пройдет по регионам:

• Americas Tuesday, February 9 at 9:30 AM PST
• EMEA Wednesday, February 10 at 9:30 AM GMT
• Asia Pacific Tuesday, February 16 at 9:00 AM (GMT +11)

Track 2 – Build and Manage Your Hybrid Cloud

Тут уже речь пойдет о построении гибридного облака с помощью решений VMware. То есть, с одной стороны, будут рассказывать о развитии онпремизной серверной линейки продуктов, построенных на платформе VMware vSphere, а с другой стороны, речь пойдет об использовании облачных решений на базе публичного облака VMware vCloud Air.

В рамках трека вам нужно будет выбрать направление cloud management platform (CMP) или hyper-converged infrastructure (HCI), хотя они не являются взаимоисключающими.

Анонс также будет разнесен по времени для различных регионов:

• Americas Wednesday, February 10 at 8:30 AM PST
• EMEA Thursday, February 11 at 9:30 AM GMT
• Asia Pacific Tuesday, February 16 at 9:00 AM (GMT +11)

Больше подробностей о мероприятии можно узнать по этой ссылке, там же можете и зарегистрироваться.

Интересная статья от Дункана Эппинга была опубликована в его блоге пару недель назад. Если вы хотите использовать виртуальные тома VVols, которые обладают некоторыми преимуществами по сравнению с традиционной файловой системой VMware VMFS, то для некоторых систем, поддерживающих механизм VASA (vSphere API for Storage Awareness), потребуется использовать внешний виртуальный модуль VASA Vendor Provider (VP). То есть, некоторые аппаратные хранилища уже содержат в себе готовые модули и прошитые в них модули VP, а вот для некоторых нужно запускать и поддерживать специальную виртуальную машину, выполняющую сервисные функции при работе виртуальных машин с хранилищами VVols.

Прежде всего VP используется для выполнения операции Bind (привязка машины к VVol), которая инициируется при запуске виртуальной машины. В этом случае VP создает точку доступа ввода-вывода (IO access point) для виртуального тома VVol на выбранном Protocol Endpoint (PE). Без этой операции машина не запустится, из чего следует, что критически важно поддерживать виртуальную машину с VP непрерывно доступной. У разных вендоров используются разные уровни доступности:

• Кто-то выпускает модуль с возможностью active/standby или active/active-конфигурации виртуальных машин на разных хостах.
• Ну а кто-то надеется на встроенные механизмы обеспечения отказоустойчивости VMware HA и VMware Fault Tolerance (FT).

Очевидно, что если вы выбираете хранилище с внешним VP, то очень желательно, чтобы там был реализован первый вариант обеспечения доступности. Ну и нельзя помещать виртуальную машину с VASA VP на том VVol, чтобы не оказаться в ловушке невозможности запуска этой виртуальной машины.

Со временем VMware планирует включить операции bind/unbind в стандарт T10 SCSI, и сервисная виртуальная машина будет не нужна, но эти вещи, как вы понимаете, делаются не быстро, поэтому пока обеспечивайте отказоустойчивость виртуальных модулей VP, по крайней мере, с помощью технологий VMware HA и VMware Fault Tolerance.

И да, в комментарии пишут, что у одного админа получилось так, что машина с VP просто перестала выполнять команды, хотя сама ВМ работала. В результате продуктивные ВМ было не запустить. Поэтому имеет смысл задуматься и об обеспечении отказоустойчивости на уровне компонентов VP (может, как-нибудь проверять скриптами его работоспособность?).

Когда вы ставите один сервер VMware ESXi, то проще всего сделать это, смонтировав ISO-образ через iLO или подобную консоль, либо воткнув загрузочную флешку непосредственно в сервер. Но если у вас несколько хост-серверов ESXi, то делать так уже несолидно для опытного администратора. В целях ускорения процесса он использует процедуру загрузки установщика хоста по сети через механизм PXE, а самые крутые администраторы уже используют средство Auto Deploy, у которого сравнительно недавно появился GUI.

На эту тему компания VMware выпустила очень полезный документ "Installing ESXi Using PXE", в котором эта процедура расписывается по шагам (как для BIOS, так и для UEFI-хостов):

Интересна диаграмма зрелости процесса установки VMware ESXi в организации. Новички прожигают исошку на диск, а крутые перцы - используют Auto Deploy для stateless-хостов:

А вот, например, основная диаграмма последовательности процессов при установке ESXi через PXE:

По шагам процедура выглядит так:

1. Администратор загружает целевой хост ESXi.

2. Этот хост делает DHCP-запрос.

3. DHCP-сервер отвечает с IP-параметрами и расположением TFTP-сервера, который содержит загрузчик.

4. ESXi обращается к серверу TFTP и запрашивает файл загрузчика, который указал DHCP-сервер.

5. TFTP-сервер посылает загрузчик хосту ESXi, который исполняет его. Начальный загрузчик догружает дополнительные компоненты с TFTP-сервера.

6. Загрузчик ищет конфигурационный файл на TFTP-сервере, скачивает ядро и другие компоненты ESXi с HTTP-сервера, который размещен на TFTP-сервере, и запускает ядро на хосте ESXi.

7. Установщик ESXi запускается в интерактивном режиме, либо используя kickstart-скрипт, который указан в конфигурационном файле.

Для автоматизации задач по подготовке ISO-образа ESXi к загрузке через PXE вы можете использовать вот этот полезный скрипт.

Компания StarWind Software, известная своим продуктом номер 1 - Virtual SAN, предназначенным для создания отказоустойчивых хранилищ под виртуализацию, в ближайший четверг проведет весьма интересный вебинар "Minimalistic Configuration of 2-Node Fault-Tolerant Hyper-V Cluster with StarWind Virtual SAN", где наглядно покажет процесс развертывания решения Virtual SAN в кластере из двух узлов Microsoft Hyper-V.

Оба этих узла используются и как хост-серверы для виртуальных машин, и как узлы отказоустойчивого кластера хранилищ. Таким образом, в небольшом филиале данная конфигурация из двух хостов может поддерживать серверную инфраструктуру всего филиала. Во время вебинара будет проведена живая демонстрация процесса пошаговой настройки кластера хранилищ и серверов:

Дата и время вебинара: 28 января в 16-00 по московскому времени. Вебинар проведет Владислав Караев, а вы сможете задавать вопросы на русском языке.

Регистрируйтесь и не пропустите отличную возможность существенно сэкономить на средствах виртуализации серверов и хранилищ для небольшой инфраструктуры.

Компания RightScale, разрабатывающая ПО в сфере универсального управления облачными инфраструктурами, зарелизила ресурс http://cloudcomparison.rightscale.com, на котором можно сравнить основные публичные облачные платформы и изучить их функциональные возможности:

На данный момент на сайте присутствуют только 4 публичных облака: Amazon AWS, Google Cloud Platform, Microsoft Azure и SoftLayer от IBM. Интересно, что с помощью фильтров слева можно узнать, какие гостевые ОС доступны, в каких странах доступен сервис, а также что облако предлагает в плане вычислительных мощностей, хранилищ и сетевых возможностей.

Даже если с практической точки зрения это вам не интересно, все равно прикольно потыкать на галочки фильтров и посмотреть, какая из платформ что умеет. Из того, что я натыкал - AWS вне конкуренции.

Компания VMware на днях выпустила новую версию своего главного средства для P2V-переноса физических серверов в виртуальную среду vCenter Converter Standalone 6.1. Напомним, что о прошлой версии Converter, которая вышла весной прошлого года, мы писали вот тут.

Посмотрим на новые возможности Converter:

• Поддержка новых гостевых ОС для переноса физических систем на базе Windows 10 и Ubuntu 15.
• Возможность офлайн-конвертации виртуальных машин с платформы Microsoft Hyper-V 2012 R2 на Workstation и vSphere.
• Аутентификация на базе ключа по SSH для исходных физических Linux-систем при P2V-миграции.
• Поддержка настольной платформы виртуализации VMware Workstation 12.

Скачать VMware vCenter Converter Standalone 6.1 можно по этой ссылке. Release notes по продукту (включая список поддерживаемых продуктов и гостевых ОС) доступны тут.

Представляем вам гостевой пост от облачного сервиса 1cloud, регулярно рассказывающего на страницах нашего сайта о перспективных технологиях. Одной из наиболее активно обсуждаемых тем уходящего года стала «революция контейнеров» — многие компании внедряют их в свою инфраструктуру, а вендоры создают новые технологии для работы с ними. Недавно мы рассказывали о новых разработках VMware в этой области, а теперь представляем вашему вниманию адаптированный перевод заметки инженера компании о сложностях и мифах, связанных с контейнерами.

Вы стали свидетелями одного из самых крупных сдвигов, произошедших в IT-индустрии. Пятнадцать лет тому назад вы могли себе представить, что буквально одним нажатием кнопки сможете перенести приложение из одной части функционирующего дата-центра в другую, не создав при этом неудобств пользователям?

VMware сделала возможным переход от аппаратного обеспечения к программному, от ручного управления к автоматизации. Используя контейнеры, старую технологию, которую упростили такие компании, как Docker и CoreOS, мы можем мгновенно запустить множество приложений на общем ядре. В ноябре 2015 года в Барселоне прошла конференция Dockercon Europe 2015, посвященная безопасности, пользовательскому интерфейсу, RBAC-авторизации и эксплуатации программного обеспечения в целом. Стоит только упомянуть эти термины, как все внимание крупных организаций тут же обратится на вас.

На конференции искали способы заполнения пропасти между разработчиками (которые любят Docker) и IT-специалистами (у которых есть и другие проблемы, которые нужно решать). Объединить задачи этих групп спеиалистов и пытается VMware, компания тратит много усилий на популяризацию технологии контейнеров. Работа ведется по нескольким фронтам: создаются инструменты и внедряются технологии, способные облегчить этот переход.

Технология контейнеров быстро стала популярной среди разработчиков, поскольку с её помощью можно легко управлять сложными распределенными и переносимыми архитектурами приложений. Именно гибкость, переносимость и простота сделали контейнеры отличным решением для создания новых приложений. Однако с большими возможностями приходит большая ответственность – необходимо решить проблемы управления и эксплуатации, полностью понять новую парадигму разработки. Давайте рассмотрим наиболее частые заблуждения о контейнерной технологии, прежде чем вы продолжите с ней знакомство. Читать статью далее->>

В конце прошлого года компания Citrix анонсировала скорую доступность новых версий своих платформ для виртуализации и доставки приложений и десктопов - XenApp 7.7 и XenDesktop 7.7. На днях же эти продукты стали доступны для загрузки. О прошлых версиях данных решений мы писали вот тут.

Давайте посмотрим на новые возможности Cirtix XenApp 7.7 и XenDesktop 7.7:

1. Функционал зон (zones).

Эти возможности позволяют оптимизировать типовую инфраструктуру географически распределенных филиалов. Можно использовать одну первичную зону (Primary Zone), на которой есть единая база данных SQL Server (Site Database) и общие компоненты инфраструктуры Citrix, а остальные зоны (Satellite Zones) получают конфигурации из центральной зоны по WAN, но запросы виртуальных ПК к контроллерам исполняются локально.

В данном случае сайт получается один, но в него входит несколько логических зон (например, датацентры в разных городах). Более подробно проблематика рассмотрена на видео ниже, а также в этой и этой статьях.

2. Улучшенные настройки баз данных.

Теперь при создании сайта XenDesktop/XenApp можно указать различные места размещения баз данных для объектов Site, Logging и Monitoring. Также компоненты Delivery Controllers можно создавать не только при создании сайта, но и позже. Более подробная информация приведена вот тут.

3. Функции Application limits.

Теперь можно задавать лимиты для доставляемых с помощью XenApp и XenDesktop приложений. Например, можно ограничить число пользователей одновременно использующих данное приложение (ограничения у него могут быть как технические, так и лицензионные) или ограничить число запущенных экземпляров приложения на пользователя.

4. Улучшенные нотификации об изменении статуса виртуальных машин.

Теперь можно настроить многократные нотификации затронутым виртуальным машинам о следующих событиях, которые произойдут в скором времени:

• Апдейт виртуальных машин в Machine Catalog с использованием нового мастер-образа.
• Перезагрузка машин в рамках Delivery Group для применения настроек.

Сообщения можно повторять каждые 5 минут за 15 минут до начала выполнения действий.

5. Поддержка API для перемещаемых сессий.

По умолчанию сессия пользователя перемещается с ним от девайса к девайсу, при этом он может пользоваться приложениями на любом устройстве. Теперь обновленный PowerShell SDK позволяет учитывать этот момент при работе через API. Ранее эта фича была экспериментальной, а теперь стала полноценной.

6. Поддержка API для развертывания ВМ из шаблонов.

Теперь виртуальные машины из шаблонов на гипервизор можно развертывать автоматизированно, используя PowerShell SDK.

7. Поддержка обновленных программных компонентов.

Теперь при установке Delivery Controller по умолчанию развертывается SQL Server 2012 Express SP2 (SP1 больше не поддерживается), также обновлены 32 и 64-битные версии Microsoft Visual C++ 2013, 2010 SP1 и 2008 SP1. Citrix Studio или VDA для Windows Desktop OS можно развернуть на Windows 10. Citrix Receiver for Mac и Citrix Receiver for Linux теперь доступны только с сайта Citrix.

8. Многочисленные улучшения Citrix Director.

О них вы можете прочитать по этой ссылке.

9. Улучшенный Skype for Business.

Теперь звонки и видео звонки будут намного качественнее и стабильнее за счет обновленного RealTime Optimization Pack.

10. Интеграция с Azure.

Теперь через Machine Creation Services (MCS) можно быстро и просто создать виртуальные машины в облаке Microsoft Azure. Также Citrix Provisioning Services поддерживается онпремизное развертывание виртуальных ПК на основе Windows 10.

11. Запись сессий в VDI-инфраструктуре.

Теперь можно использовать Session Recording for VDI для записи сессии пользователя виртуального ПК (администратор может так записывать обучающее видео для пользователя или, наоборот, попросить его записать возникшую проблему).

Более подробно о фичах нового релиза можно прочитать в этой статье (там же и про объявленные возможности следующей версии Citrix XenApp 7.8 и XenDesktop 7.8).

Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.

Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:

Интересную новость мы обнаружили вот тут. Оказывается утилита esxtop может работать в режиме повтора для визуализации данных о производительности, собранных в определенный период времени (многие администраторы знают это, но далеко не все). Это позволит вам собрать данные о производительности хоста, например, ночью, а в течение рабочего дня проанализировать аномальное поведение виртуальной инфраструктуры VMware vSphere. Называется этот режим replay mode.

Для начала запустите следующую команду для сбора данных на хосте VMware ESXi:

# vm-support -p -d 120 -i 10 -w /vmfs/volumes/your_datastore

Объяснение параметров:

• -p - собирать только данные о производительности is to only gather performance data
• -d - длительность сбора (здесь 120 секунд)
• -i - интервал сбора данных (тут раз в 10 секунд)
• -w - хранилище куда положить выходной файл

Файл по умолчанию создается сжатым, поэтому разжимаем его следующей командой:

# tar -xzf filename.tgz

Запускаем режим воспроизведения данных следующей командой:

# esxtop -R extracted_content_file_name

И вот видим привычный нам вывод esxtop, который будет обновляться с указанным при записи данных интервалом:

Если при запуске esxtop replay mode вы получите ошибку такого вида:

No such file or directory esxtop […] all vm-support snapshots have been used

То просто запустите предварительно скрипт reconstruct.sh, который будет находиться в папке с разархивированным содержимым после отработки tar:

# ./reconstruct.sh

Компания StarWind Software, производитель лучшего средства для создания отказоустойчивых хранилищ StarWind Virtual SAN, 20 января проводит бесплатный вебинар о программно-аппаратном комплексе хранилищ "Complete Hyperconvergence with StarWind HyperConverged Appliance":

Вебинар пройдет 20 января в 22-00 по московскому времени. Участие бесплатное.

На вебинаре речь пойдет об унифицированном решении на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager (подробнее - тут).

Приходите на вебинар, посмотрите живую демонстрацию совместной работы перечисленных компонентов и узнайте, каким образом с помощью данного комплекса вы сможете существенно сэкономить финансовые ресурсы при условии решения текущих задач по надежному хранению виртуальных машин.

Мы часто пишем о том, что снапшоты в VMware vSphere - это плохо (за исключением случаев, когда они используются для горячего резервного копирования виртуальных машин и временного сохранения конфигурации ВМ перед обновлением).

Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.

Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):

О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.

Сначала посмотрим, какие факторы влияют на время процесса консолидации снапшотов виртуальной машины:

• Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
• Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
• Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
• Тип данных в файлах снапшотов (нули или случайные данные).
• Нагрузка на хост-сервер ESXi при снятии снапшота.
• Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.

Тут надо отметить, что процесс консолидации - это очень требовательный к подсистеме ввода-вывода процесс, поэтому не рекомендуется делать это в рабочие часы, когда производственные виртуальные машины нагружены.

Итак, как можно оценивать производительность процесса консолидации снапшотов:

Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.

Для реализации этого способа нужно, чтобы на хранилище осталась только одна тестовая виртуальная машина со снапшотами. С помощью vMotion/Storage vMotion остальные машины можно с него временно убрать.

1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:

ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"

2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).

3. Запускаем команду мониторинга производительности:

# esxtop

4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.

5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).

Таким образом, зная ваши параметры производительности чтения/записи, а также размер снапшотов и время консолидации тестового примера - вы сможете оценить время консолидации снапшотов для других виртуальных машин (правда, только примерно того же профиля нагрузки на дисковую подсистему).

Смотрим на производительность конкретного процесса консолидации снапшотов.

Это более тонкий процесс, который можно использовать для оценки времени снапшота путем мониторинга самого процесса vmx, реализующего операции со снапшотом в памяти сервера.

1. Запускаем команду мониторинга производительности:

# esxtop

2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.

3. Находим ВМ, на которой идет консолидация.

4. Нажимаем клавишу <e> для раскрытия списка.

5. Вводим Group World ID (это значение в колонке GID).

6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).

7. Нажимаем <u> для отображения статистики дискового устройства.

8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.

9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).

10. Отслеживаем среднее значение в колонке MBWRTN/s.

Это более точный метод оценки и его можно использовать даже при незначительной нагрузке на хранилище от других виртуальных машин.

На днях компания Veeam Software, производитель решения номер один для резервного копирования виртуальных машин, объявила о полной доступности пакета продуктов Veeam Availability Suite v9, включающего в себя Veeam Backup and Replication 9 и Veeam ONE 9.

Напомним, что Veeam Availability Suite - это самое продвинутое в отрасли решение для всесторонней защиты данных средствами резервного копирования и репликации, а также набор продуктов для управления и мониторинга виртуальной среды. По-сути, это все что нужно, кроме самой платформы VMware vSphere или Microsoft Hyper-V, чтобы организовать виртуальный датацентр с непрерывной доступностью сервисов в виртуальных машинах.

Приведем ниже основные новые возможности Veeam Availability Suite v9, касающиеся его основного компонента - Veeam Backup and Replication 9:

1. Интеграция с технологией EMC Storage Snapshots в Veeam Availability Suite v9.

Многие пользователи Veeam Backup and Replication задавали вопрос, когда же будет сделана интеграция с дисковыми массивами EMC. Теперь она добавлена для СХД линеек EMC VNX и EMC VNXe.

Интеграция с хранилищами EMC означает поддержку обеих техник - Veeam Explorer for Storage Snapshots recovery и Backup from Storage snapshots, то есть можно смотреть содержимое снапшотов уровня хранилища и восстанавливать оттуда виртуальные машины (и другие сущности - файлы или объекты приложений), а также делать бэкап из таких снапшотов.

Иллюстрация восстановления из снапшота на хранилище EMC:

Иллюстрация процесса резервного копирования (Veeam Backup Proxy читает данные напрямую со снапшота всего тома, сделанного на хранилище EMC):

Более подробно об этих возможностях можно почитать в блоге Veeam.

2. Veeam Cloud Connect - теперь с возможностью репликации.

Как вы помните, в прошлом году компания Veeam выпустила средство Veeam Cloud Connect, которое позволяет осуществлять резервное копирование в облако практически любого сервис-провайдера. Теперь к этой возможности прибавится еще и возможность репликации ВМ в облако, что невероятно удобно для быстрого восстановления работоспособности сервисов в случае большой или маленькой беды:

Кстати, Veeam Cloud Connect инкапуслирует весь передаваемый трафик в один-единственный порт, что позволяет не открывать диапазоны портов при соединении с инфраструктурой сервис-провайдера. Очень удобно.

При восстановлении в случае аварии или катастрофы основного сайта, возможно не только полное восстановление инфраструктуры, но и частичное - когда часть продуктивной нагрузки запущено на основной площадке, а другая часть (например, отказавшая стойка) - на площадке провайдера. При этом Veeam Backup обеспечивает сетевое взаимодействие между виртуальными машинами обеих площадок за счет встроенных компонентов (network extension appliances), которые обеспечивают сохранение единого пространства адресации.

Ну а сервис-провайдеры с появлением репликации от Veeam получают в свои руки полный спектр средств для организации DR-площадки в аренду для своих клиентов:

Более подробно об этой возможности можно прочитать в блоге Veeam по этой ссылке.

3. Прямой доступ к хранилищам NAS/NFS при резервном копировании.

Veeam Availability Suite v9 поддерживает прямой доступ к хранилищам NAS/NFS при резервном копировании. Раньше пользователи NFS-массивов чувствовали себя несколько "обделенными" в возможностях, так как Veeam не поддерживал режим прямой интеграции с таким типом дисковым массивов, как это было для блочных хранилищ.

Теперь же появилась штука, называемая Direct NFS, позволяющая сделать резервную копию ВМ по протоколам NFS v3 и новому NFS 4.1 (его поддержка появилась только в vSphere 6.0), не задействуя хост-сервер для копирования данных:

Специальный клиент NFS (который появился еще в 8-й версии) при включении Direct NFS получает доступ к файлам виртуальных машин на томах, для которых можно делать резервное копирование и репликацию без участия VMware ESXi, что заметно повышает скорость операций.

Кроме этого, была улучшена поддержка дисковых массивов NetApp. В версии 9 к интеграции с NetApp добавилась поддержка резервного копирования из хранилищ SnapMirror и SnapVault. Теперь можно будет создавать аппаратные снимки (с учетом состояния приложений) с минимальным воздействием на виртуальную среду, реплицировать точки восстановления на резервный дисковый массив NetApp с применением техник SnapMirror или SnapVault, а уже оттуда выполнять бэкап виртуальных машин.

При этом процесс резервного копирования не отбирает производительность у основной СХД, ведь операции ввода-вывода происходят на резервном хранилище:

Ну и еще одна полезная штука в плане поддержки аппаратных снимков хранилищ от Veeam. Теперь появится фича Sandbox On-Demand, которая позволяет создать виртуальную лабораторию, запустив виртуальные машины напрямую из снапшотов томов уровня хранилищ. Такая лаборатория может быть использована как для проверки резервных копий на восстановляемость (сразу запускаем ВМ и смотрим, все ли в ней работает, после этого выключаем лабораторию, оставляя резервные копии неизменными), так и для быстрого клонирования наборов сервисов (создали несколько ВМ, после чего создали снапшот и запустили машины из него). То есть, можно сделать как бы снимок состояния многомашинного сервиса (например, БД-сервер приложений-клиент) и запустить его в изолированном окружении для тестов, ну или много чего еще можно придумать.

Вот здесь вы можете узнать больше подробностей об этой возможности в блоге Veeam.

Читать статью далее ->>